Robot communication overview

This page gives a general description of the communication between the vision controller and the robot controller.

Contents

1 Architecture

1.1 Robot interface and Robot module

The vision controller and the robot controller communicate through two parts: the Robot interface on the vision controller and the Robot module on the robot controller.

The vision controller comes with Robot interfaces for all supported robot brands.
You must install the Robot module for your robot brand on the robot controller. Without it, the robot controller cannot communicate with the Robot interface. The section Robot module contents describes the Robot module and its contents.
Image 1 - Architecture of the Robot communication

Image 1 - Architecture of the Robot communication

1.2 TCP/IP based

The vision controller and the robot controller communicate over the TCP/IP protocol. On some robot controllers, network communication is not included by default and is available only as an additional option. The Prerequisites section of each Robot integration guide lists everything you need to install the Robot module.

Note: No other communication protocols are currently supported.

1.3 Communication channels

The communication between the vision controller and the robot controller uses two channels with different purposes. Each channel has a TCP server on one side and a TCP client on the other side. The channels are:

  • Action Request Communication Channel

    The vision controller creates a TCP server and the Robot module acts as a TCP client. The server is called the Action Request Server and the client is called the Action Request Client.

    The Action Request Client sends action requests to the Action Request Server through this channel. The vision controller executes the action request and sends a response back to the robot controller.

  • Robot State Communication Channel (needed by Bin Picking Studio, optional for Locator Studio)

    The Robot module creates a TCP server and the vision controller acts as a TCP client. The server is called the Robot State Server and the client is called the Robot State Client.

    The Robot State Server sends robot state data to the Robot State Client through this channel. The robot state data are used:

    • when you teach a gripping point

    • when you calibrate a vision system

    • during the deployment of hand-eye vision systems

    • for real-time visualization of the robot movement

Image 2 - Robot communication channels

Image 2 - Robot communication channels

1.4 Serial and parallel program execution

The Robot module implements the communication in a slightly different way for each robot brand. On some brands, the communication runs in a single (main) task. On other brands, it runs in a separate task, and the main task interacts with this task.

Serial program execution
Brands: ABB, Doosan, Estun, Hyundai Robotics, Kassow Robots, Kawasaki, KUKA, Techman Robot, Universal Robots

The motion commands and the communication with the vision controller run in a single main task.

Parallel program execution
Brands: FANUC, Stäubli, Yaskawa

The part of the program that communicates with the vision controller runs in a separate background task. The main task (motion commands, etc.) runs on the teach pendant. It synchronizes with the background task through flags and exchanges data with it through registers.

1.5 Ports and brand ID

Communication channels and ports

Communication channels and ports

Channel

Default port

Notes

Action Request Server (vision controller)

11003

The port can be changed on the Network page of the Studio. Only one Action Request Client can be connected at a time. The KUKA KRC Robot module connects to port 54601, so set this port on the Network page.

Robot State Server (robot controller)

11004

Needed by Bin Picking Studio. Locator Studio uses it only if the Robot module provides one, to show the robot and to add calibration points - see the Robot module support matrix. Universal Robots do not need it - the vision controller reads the robot state directly from the UR controller. The KUKA KRC Robot State Server listens on port 54602.

Right after the connection is established, the Robot module sends its brand ID. The brand ID is a 24-character text that contains the robot brand and the version of the communication interface (for example ABB_IRB/1.12.0XXXXXXXXXX). The vision controller uses it to select the robot brand and the message format. If the brand or the version is not supported, the vision controller closes the connection. The brand IDs of all Robot modules are listed in the Robot module support matrix.

2 General principles

2.1 Persistence

The Robot interface on the vision controller is available right after the vision controller starts and runs until it shuts down.
The Action Request Server on the vision controller always waits for the Action Request Client to connect. In the same way, the Robot State Client tries to connect to the Robot State Server again and again.

If you change network parameters on the Network page of the Studio and press the Save button, the affected part of the Robot interface restarts.

2.2 Automatic brand recognition

When a new connection is established, the vision controller detects the brand of the connected robot automatically. This makes correct communication with the robot controller possible.

Bin Picking Studio

The brand is validated when the vision controller receives the Initialization request and the Add calibration point request. This makes sure that the brand of the connected robot matches the robot brand selected in the BPS solution.
The robot model is not validated, because the Robot module is specific to a robot brand, not to individual robot models. The BPS user must select the correct robot model in the solution that is deployed with the connected robot.

2.3 Full operator control

The Studio on the vision controller does not take control of the robot. It only sends responses to the action requests through the Action Request Communication Channel. For example, it sends a trajectory and gripper commands in BPS, or the pose of the localized object in LS.
When you install the Robot module, the Photoneo robotic API is added to the standard function library of the robot. The robot programmer/operator decides when to send an action request and what to do with the result in the response.

Bin Picking Studio

The robot programmer must implement the gripper commands and configure the parameters of the bin picking routine (motion speed, acceleration, accuracy, etc.).

The robot programmer/operator can always follow the execution of the robot program directly on the teach pendant. Background tasks never execute motions, so all motions stay under the control of the programmer/operator.

Be extremely careful, especially during the first commissioning. Always make sure that the motion speed and acceleration are set correctly. Be ready to stop the robot program immediately if necessary.

2.4 Easy to integrate

Robot modules are designed for easy integration into existing robot applications written in standard robot languages. For the robot programmer, the Robot module is a set of jobs/routines/programs that the programmer/operator can call when needed.

3 Brand support and Robot module contents

3.1 Supported robot brands

Bin Picking Studio

Bin Picking Studio is compatible with a wide range of industrial robots from different manufacturers. The current version supports the following robot brands:

Robot modules for older versions only: Doosan, Hyundai Robotics, KUKA LBR iiwa, RobCo, Stäubli.

Locator Studio

Photoneo offers Robot modules for Locator Studio for the following robot brands:

Robot modules for older versions only: Doosan, Hyundai Robotics, RobCo.

For LS, you can also write your own Action Request Client (TCP/IP client) on any compatible robot controller or system (PLC). The specification of the communication protocol is available on request.

3.2 Robot module contents

The Robot module consists of:

  • Photoneo robotic API A set of procedures (jobs/routines/programs) written in the native programming language(s) of the robot brand. Use these procedures to communicate with the Studio easily.

  • Example programs Several simple robot programs that show different approaches for standard applications.

  • Integration guide A guide that describes how to configure the robot controller for the Studio, how to install the Robot module, the API, and how to use it.

The Robot module is a ZIP archive. You can download it from the official Photoneo website. The current versions are listed in the Robot module support matrix.